Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-222.txt

Text File | 1994-12-08 | 32.2 KB | 833 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 06 Dec 92       Volume 1 : Issue 222

Today's Topics:

    System 7.0 popup CDEF works in dialogs / not in windows?
    OS Queues (Enqueue and Dequeue) at Interrupt time?
    Process Manager - no threads? (!)
    Multi-Tasking Problems
    C.S.M.P. Digest Easy View format file



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  You can post articles to any newsgroup by
mailing your article to [e-mail].  So, to post an
article to comp.sys.mac.programmer, you mail it to
[e-mail].  Note the '-' instead of '.'
in the newsgroup name.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Mike Engber)
Subject: System 7.0 popup CDEF works in dialogs / not in windows?
Date: 2 Nov 92 23:08:03 GMT
Organization: The Institute for the Learning Sciences


I'm having trouble getting the System 7.0 & 7.1 popup menu CDEF
to work in a regular window. It works fine in dialogs. In the
window, I call TrackControl - the title inverts & tracks the mouse,
but the menu doesn't pop.

Any ideas?

I'm pretty sure I covered all the obvious - the 'MENU' rsrc specified
in contrlMin really exists. The control draws itself fine - with the
first item in the 'MENU' rsrc showing in the popup box.

I'm pretty mystified.

please cc via email if possible

- -ME

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Date: 3 Nov 92 09:15:46 GMT
Organization: Whole Earth 'Lectronic Link

In article <[e-mail]> [e-mail] (Mike Engber) writes:
>I'm having trouble getting the System 7.0 & 7.1 popup menu CDEF
>to work in a regular window. It works fine in dialogs.

When you create the control, remember to set the contrlAction field to -1,
so the control will autotrack. This is what the dialog manager does.

+++++++++++++++++++++++++++

From: [e-mail] (Mike Engber)
Organization: The Institute for the Learning Sciences
Date: Tue, 3 Nov 1992 16:13:28 GMT

>I'm having trouble getting the System 7.0 & 7.1 popup menu CDEF
>to work in a regular window. It works fine in dialogs. In the
>window, I call TrackControl - the title inverts & tracks the mouse,
>but the menu doesn't pop.

I got at least one "me too" + lots of correct responses so far.
So I figure it's worth posting the simple soln.

You need to pass -1 to TrackControl for the actionProc. Apparantly, the menu
popping is performed by the CDEF's track routine.

It seems like passing -1 for the actionProc is the right thing to do in
general - don't know why I got into the habit of passing NULL.

While I'm on the subject of the Sytem popup CDEF has anyone noticed:

 - The version in 7.1 no longer uses the 'mctb' resource to color
   the menu. In 7.0  the 'mctb' info was used (not necessarily in
   the way I would have used it, but it was used)

 - In both 7.0 and 7.1 the control color table is ignored. It's think
   it would be used for picking the frame and title color. Perhaps
   even the popup box background & text color in the abscence of a
   'mctb' rsrc.

 - The menu title jumps around to align itself with the top of
   the current item. This is only noticable if the items vary
   in height (i.e. some have icons). I'd think it would be preferable
   to just vertically center the title as is done with the popup box.

 - Clicking on the title area pops the menu. I would have assumed this
   was a dead area & only hitting the popup box mattered. I guess I
   can't see any reason not to make the title area hot - but there sure
   aren't any visual clues that it is.

- -ME

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 3 Nov 1992 16:14:33 GMT

[e-mail] (Mike Engber) writes:


>I'm having trouble getting the System 7.0 & 7.1 popup menu CDEF
>to work in a regular window. It works fine in dialogs. In the
>window, I call TrackControl - the title inverts & tracks the mouse,
>but the menu doesn't pop.
>Any ideas?

You need to do TrackControl(popupControlHandle,&clickPt,(ProcPtr)-1);
If you don't use -1, the CDEF's action proc won't be called.

- -Ivan

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Date: Tue, 3 Nov 1992 21:19:22 GMT

In article <[e-mail]> [e-mail] (Mike Engber) writes:
>While I'm on the subject of the Sytem popup CDEF has anyone noticed:
>
> - The version in 7.1 no longer uses the 'mctb' resource to color
>   the menu. In 7.0  the 'mctb' info was used (not necessarily in
>   the way I would have used it, but it was used)
>
    Yup!  This is because I bitched enough to get it put on the Apple
bug list since the popUP looks REALLY ugly when used on computers with
custom mctb's - especially with non-white background colors.

> - In both 7.0 and 7.1 the control color table is ignored. It's think
>   it would be used for picking the frame and title color. Perhaps
>   even the popup box background & text color in the abscence of a
>   'mctb' rsrc.
>
    I believe the reasoning here was that even though it is a control, it
should use the MENU information.  I could see this going either way. However,
also remember that the PopUp was originally written for S'ystem 6 (CTB) where
the control color table acted differently.

> - The menu title jumps around to align itself with the top of
>   the current item. This is only noticable if the items vary
>   in height (i.e. some have icons). I'd think it would be preferable
>   to just vertically center the title as is done with the popup box.
>
    Never noticed this, but I believe it.

> - Clicking on the title area pops the menu. I would have assumed this
>   was a dead area & only hitting the popup box mattered. I guess I
>   can't see any reason not to make the title area hot - but there sure
>   aren't any visual clues that it is.
>
    Just like clicking on the title of a checkbox (or radio button) is
the same as clicking the "box".



- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician


+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: Wed, 4 Nov 92 13:02:43 EST
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Leonard Rosenthol) writes:
> > - Clicking on the title area pops the menu. I would have assumed this
> >   was a dead area & only hitting the popup box mattered. I guess I
> >   can't see any reason not to make the title area hot - but there sure
> >   aren't any visual clues that it is.
> >
>     Just like clicking on the title of a checkbox (or radio button) is
> the same as clicking the "box".

Agreed. And I think this functioning is *vital*. It allows me to look
at the menu without "reselecting" the current selection. The problem
is that some menu picks involve an action, and sometimes I simply
do not want the action taken. By clicking on the title, I can get
a look at the other items without highlighting any of them. Otherwise,
I have to drag the mouse out of the menu before releasing.



tim endres - [e-mail]  -or- tbomb!time
ICE Engineering, Inc - 8840 Main St, Whitmore Lake, MI 48189
Phone [phone] - FAX [phone]
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Jeremy Roussak)
Date: 4 Nov 92 21:36:56 GMT
Organization: Computer Science Dept, QMW, University of London

In <[e-mail]> [e-mail] (Tim Endres) writes:

>>      Just like clicking on the title of a checkbox (or radio button) is
>> the same as clicking the "box".

>Agreed. And I think this functioning is *vital*. It allows me to look
>at the menu without "reselecting" the current selection. The problem
>is that some menu picks involve an action, and sometimes I simply
>do not want the action taken. By clicking on the title, I can get
>a look at the other items without highlighting any of them. Otherwise,
>I have to drag the mouse out of the menu before releasing.

I agree that the analogy with the titles of checkboxes and
radio buttons is valid. However, I think Tim's reasoning is
faulty: any application which doesn't allow you to click on a
popup menu and release your button *without moving the mouse*
is breaking Apple's guidelines on popup menus, which
specifically comment on this. It's the programmers'
responsibility to ensure that you can click-release on popup
menus without changing things. Some applications do break these
guidelines, notably those which use popups for styles, in which
the object is to check or uncheck each item, rather than to
choose one from the menu. THINK C breaks the rules in its
Project Type dialog in this way, too.

Perhaps we could discuss this: is a popup menu a suitable way
of implementing this kind of selection?

Jeremy

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Wed, 4 Nov 1992 21:30:10 GMT

[e-mail] (Tim Endres) writes:

>> > - Clicking on the title area pops the menu. I would have assumed this
>> >   was a dead area & only hitting the popup box mattered. I guess I
>> >   can't see any reason not to make the title area hot - but there sure
>> >   aren't any visual clues that it is.
>> >
>>     Just like clicking on the title of a checkbox (or radio button) is
>> the same as clicking the "box".

>Agreed. And I think this functioning is *vital*. It allows me to look
>at the menu without "reselecting" the current selection. The problem
>is that some menu picks involve an action, and sometimes I simply
>do not want the action taken. By clicking on the title, I can get
>a look at the other items without highlighting any of them. Otherwise,
>I have to drag the mouse out of the menu before releasing.

Except that the popup menu control doesn't work as you describe, at
least in System 7.0 with 1.1.1 Tuneup. When you mouse down on a normal
button and release the mouse when it is outside of the button,
TrackControl returns 0. If you do the equivalent on a popup menu
control, releasing while you are not on the menu, TrackControl returns
1. This is the wrong behavior, as far as I can tell.

But even if TrackControl did return 0 if you pull out of the menu
(which I agree it should), the behavior that you like, of clicking and
releasing on the title not counting as hitting the control, is exactly
the opposite of what clicking the title of a checkbox does; clicking
on the title of a control counts as a hit, though TrackControl may
want to return some value indicating that was just a title hit as
opposed to a menu hit. Either way, the 7.0 popup menu CDEF is doing it
wrong.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mike Engber)
Date: 4 Nov 92 23:25:17 GMT
Organization: The Institute for the Learning Sciences

>...
>specifically comment on this. It's the programmers'
>responsibility to ensure that you can click-release on popup
>menus without changing things. Some applications do break these
>guidelines,

Try popping on the very bottom of the standard System 7.0 popup CDEF.
It comes up with the next item down hilited. The reason is the distance
from the top of the popup box to the bottom is greater than the height
of the menu item. This is fixable by narrowing the hit area 1 pixel (as
I do in my CDEF).

But here's a case w/o such an easy fix. The type-in popup menu
CDEF which I've been working on has a popup box which is necessarily
much taller than a menu item. This is because it's height matches
the frame of an edit text item.

I can't narrow the hot area that much without it being a big
irritation to users. I've no idea what to do. I tried nudging
the mouse up a bit - it's too un-nerving.

If anyone has a soln I'd love to hear it.

>notably those which use popups for styles, in which
>the object is to check or uncheck each item, rather than to
>choose one from the menu. THINK C breaks the rules in its
>Project Type dialog in this way, too.
>
>Perhaps we could discuss this: is a popup menu a suitable way
>of implementing this kind of selection?

Perhaps one that just puts the title in the popup box and the
items are only shown when it's popped. I have such a CDEF if you
want to try it. It doesn't currently do the checking and unchecking,
but that could easily be added.

---------------------------

From: Mel Walker <[e-mail]>
Subject: OS Queues (Enqueue and Dequeue) at Interrupt time?
Organization: Society for Anarchic Totalitarianism
Date: Wed, 4 Nov 1992 21:41:17 GMT

Can I use Enqueue() and Dequeue() at interrupt time? Reading IM, I'm not
sure. It seems that they turn off interrupts, but do they move memory? It
would seem that they would have to. Yet, it also seems like they
don't.(?) Would someone please clarify this for me?

- --Mel Walker
[e-mail]
Disclaimer: Some Martians landed and stole my opinions. So if these
opinions sound like they're coming from Mars, that's why.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 5 Nov 92 01:46:43 GMT
Organization: Taligent

In article <[e-mail]>, Mel Walker <[e-mail]> wrote:
>
> Can I use Enqueue() and Dequeue() at interrupt time? Reading IM, I'm not
> sure. It seems that they turn off interrupts, but do they move memory? It
> would seem that they would have to. Yet, it also seems like they
> don't.(?) Would someone please clarify this for me?

Yes, you can definitely call Enqueue and Dequeue at interrupt time. That's
what they are for. For instance, events such as key-down, mouse-down, and
disk-inserted are posted to the event queue at interrupt time with those
routines.

All those routines do is add a record to a linked list of records. They
don't move memory (I'm not sure why you think they do).

I believe that an upcoming issue of "develop" will have an article showing
how to use the queue routines for scheduling serialized asynchronous
activity.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 5 Nov 92 01:56:55 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, Mel Walker <[e-mail]> wrote:
>
> Can I use Enqueue() and Dequeue() at interrupt time? Reading IM, I'm not
> sure. It seems that they turn off interrupts, but do they move memory? It
> would seem that they would have to. Yet, it also seems like they
> don't.(?) Would someone please clarify this for me?
>
> --Mel Walker
> [e-mail]
> Disclaimer: Some Martians landed and stole my opinions. So if these
> opinions sound like they're coming from Mars, that's why.

Yes, Enqueue and Dequeue are entirely safe to call at interrupt time;
they're the safest way to maintain lists in this kind of a situation.

They don't need to allocate memory because you're responsible for
allocating the memory for your queue entries; many people will allocate
room for a number of entries as an array, then have two queues; one
of available entries, and one of entries queued for processing.
Thus, your task would Dequeue an empty block from the empty chain,
fill it out, then Enqueue into the active queue.

Hope this helps (TM)
Tim Dierks, but if I only had a .signature....

---------------------------

From: [e-mail] (Peter Creath)
Subject: Process Manager - no threads? (!)
Date: 23 Oct 92 00:04:00 GMT
Organization: Cube Technologies

I paged through the "IM: Processes" today and found, to my chagrin,
no threading capabilities!

Surely when Apple release System 7 with interapplication communication
and launching, etc. and the advent of the Process Manager they didn't
leave out spawned child processes?

(SIGH.  I guess this means I'll have to write messy code to internally
multitask until System 8, right?)

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]           become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (Daniel Norman Johnson)
Date: 26 Oct 92 14:47:24 GMT
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <[e-mail]>, [e-mail] (Peter Creath) writes:
|> I paged through the "IM: Processes" today and found, to my chagrin,
|> no threading capabilities!
|>
|> Surely when Apple release System 7 with interapplication communication
|> and launching, etc. and the advent of the Process Manager they didn't
|> leave out spawned child processes?

Yep. :( You could write a separate (background) app and lauch THAT,
but its still messy.

|> (SIGH.  I guess this means I'll have to write messy code to internally
|> multitask until System 8, right?)
|>                                                            -- Clarence Darrow

Well, you could. However there's a rather neat threading package called
the "Task Manager" availiable at the usual ftp sites which does an excelent
job of hiding the messyness from you. 'Tis only co-operative, and it
saves your context by making a copy of teh stack (Rather than just moving
the stack pointer to the next threads stack), but other than that it seems
very nice to me. Take a look.

PS, does anyone know if the sort of stack-copying this thing does
is evilnastybad and probably incomatible with System 27.2?
- --
            - Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: Tue, 27 Oct 1992 03:57:11 GMT
Organization: Apple

In article <[e-mail]>, [e-mail]
(Peter Creath) wrote:
>
> I paged through the "IM: Processes" today and found, to my chagrin,
> no threading capabilities!

Check out the Michael Gough article in develop #7, some people use
it, even if I've heard valid critique about this package (source code
is part of the article). Otherwise, as product managers say, stay
tuned for future information.

Kent
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Hammett)
Date: 27 Oct 92 20:46:51 GMT
Organization: University of Auckland, New Zealand.

[e-mail] (Kent Sandvik) writes:
>Check out the Michael Gough article in develop #7, some people use
>it, even if I've heard valid critique about this package (source code
>is part of the article). Otherwise, as product managers say, stay
>tuned for future information.

Source code to the Threads package is not part of the article. As far as
I know, source to the package has not been released. There is,
however, code which shows how to use the package.

- --
Tim Hammett, Botany Dept, Auckland University, New Zealand.
[e-mail]   Phone: [phone] x8365    FAX: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Carol Cantrell)
Date: 2 Nov 92 16:59:37 GMT
Organization: Colorado State University, Fort Collins, CO  80523

How do I go about changing trap addresses from within an INIT?  And how do I
make an INIT that continuously operates in the background?  There doesn't seem
to be any help on this in Inside Mac.

Paul Cantrell
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon Wtte)
Date: 2 Nov 92 21:22:11 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

[e-mail] (Carol Cantrell) writes:

   How do I go about changing trap addresses from within an INIT?  And how do I
   make an INIT that continuously operates in the background?  There doesn't seem
   to be any help on this in Inside Mac.

Of course there is.

NSetTrapAddress and jGNEFilter respectively.

- --
 -- Jon W{tte, [e-mail], Mac Hacker Suedoise (not french speaking) --
  "It was, in fact, cool as all get-out.  Fortunately it was a little
   too late (historically speaking) to be groovy."
                     -- Dennis Pelton

+++++++++++++++++++++++++++

From: [e-mail] (Carol Cantrell)
Date: 3 Nov 92 04:37:35 GMT
Organization: Colorado State University, Fort Collins, CO  80523

In article <[e-mail]> [e-mail] (Jon Wtte) writes:
>[e-mail] (Carol Cantrell) writes:
>
>   How do I go about changing trap addresses from within an INIT?  And how do I
>   make an INIT that continuously operates in the background?  There doesn't seem
>   to be any help on this in Inside Mac.
>
>Of course there is.
>
>NSetTrapAddress and jGNEFilter respectively.

I guess I'm just incredibly dense, but I this doesn't help!  I've tried
NSetTrapAdress, but I can't get my INIT to allocate anything permanently in
the system heap!  I've tried NewHandle, NewPtr, NewPtrSys,
SetZone(SystemZone()), etc, and of course I have a sysz resource, but none
of it does any good.

As for JGNEFilter, I found it defined as a low-mem global in a Think C
header, but it isn't documented in the Think C manual, or in Inside Mac's
indexes in vol. 1, 2, 3, 4, 5, 6, or X-ref under constants or field names.
Where is it?  What is it?

Thanks!  I'm desperate!

Paul Cantrell
[e-mail]

"In the beginning, the universe was created.  This has made a lot of people
very angry and has been widely regarded as a bad move." --Douglas Adams


+++++++++++++++++++++++++++

From: [e-mail] (John Wallace)
Organization: TRW Sensor Data Processing Center, Redondo Beach, CA
Date: Wed, 4 Nov 92 21:41:46 GMT

In article <[e-mail]> [e-mail] (Carol Cantrell) writes:
>
>I've tried
>NSetTrapAdress, but I can't get my INIT to allocate anything permanently in
>the system heap!  I've tried NewHandle, NewPtr, NewPtrSys,
>SetZone(SystemZone()), etc, and of course I have a sysz resource, but none
>of it does any good.
>

You have to load your code into the system heap.  At INIT time, your
INIT loads into its own application heap that is destroyed as soon as
your INIT quits to allow the Mac to continue to boot.  If you want
your patches to hang around, you must load your code into the system
heap.

>As for JGNEFilter, I found it defined as a low-mem global in a Think C
>header, but it isn't documented in the Think C manual, or in Inside Mac's
>indexes in vol. 1, 2, 3, 4, 5, 6, or X-ref under constants or field names.
>Where is it?  What is it?

jGNEFilter is a pointer located at $29A.  It contains pointer to a
procedure which is executed whenever a call to GetNextEvent or
WaitNextEvent is called.  It gives you the opportunity to do processing
with an event before it is returned to the caller.  The event is passed
in a register (I cannot remember which one).

When you patch jGNEFilter, you must save the previous value in
jGNEFilter so that you can jump to the old filter after you process the
event yourself.  Otherwise all of the other folks that patch jGNEFilter
(like screensavers) will stop functioning.

I recommend that you get Scott Knaster's "How to Write Macintosh
Software" if you are interested in understanding how the Mac works at
a lower level.

You also should invest in MacNosy from Steve Jasik.  The only way that
you find out how a lot of the low-memory globals are used is to
disassemble the ROM.

>
>Paul Cantrell
>[e-mail]
>

Cheers!
John
- ----------
John Wallace     [e-mail]


---------------------------

From: [e-mail] (Jerome Chan)
Subject: Multi-Tasking Problems
Date: 23 Oct 1992 15:52:38 GMT
Organization: The Tofu Society of Singapore

  I use At Ease 1.0 and System 7.0.1.

  When running without the finder, some of the applications I use (e.g.
NewsWatcher) won't allow me to use the application menu to switch to
another application when it is busy. When running with the finder, I can
switch out of the same situation just by clicking onto the desktop window.

  Does anyone know why the Macintosh behaves in this manner?

- ---
 The Evil Tofu

+++++++++++++++++++++++++++

From: [e-mail] (Sandra Stewart-Cole)
Date: 28 Oct 92 19:08:39 GMT
Organization: University of Illinois at Urbana

In <[e-mail]> [e-mail] (Jerome Chan)
writes:

>  I use At Ease 1.0 and System 7.0.1.

>  When running without the finder, some of the applications I use (e.g.
>NewsWatcher) won't allow me to use the application menu to switch to
>another application when it is busy. When running with the finder, I can
>switch out of the same situation just by clicking onto the desktop window.

>  Does anyone know why the Macintosh behaves in this manner?

The key is in how each program is handling the application menu. The bottom
line is that careless programming that worked before there WAS an app menu
sometimes doesn't work now that the system has changed.

+++++++++++++++++++++++++++

From: [e-mail] (Jerome Chan)
Date: 28 Oct 92 21:21:59 GMT
Organization: The Tofu Society of Singapore

In article <[e-mail]>, [e-mail] (Sandra
Stewart-Cole) wrote:

> The key is in how each program is handling the application menu. The bottom
> line is that careless programming that worked before there WAS an app menu
> sometimes doesn't work now that the system has changed.

So how should the App Menu be handled? Do you have a clue?

- ---
 The Evil Tofu

+++++++++++++++++++++++++++

From: [e-mail] (Sandra Stewart-Cole)
Organization: University of Illinois at Urbana
Date: Tue, 3 Nov 1992 20:35:25 GMT

In <[e-mail]> [e-mail] (Jerome Chan)
writes:

>> The key is in how each program is handling the application menu. The bottom
>> line is that careless programming that worked before there WAS an app menu
>> sometimes doesn't work now that the system has changed.

>So how should the App Menu be handled? Do you have a clue?

Frankly, I haven't a clue, beyond properly ignoring it. I haven't seen the
particular problemn arise in my own programs, and I can't watch exactly how
your problem is showing up, but I know that I have seen programs ignore the
application menu when they are busy, and yet have seen others that were
written long before system 7 that let it work fine. Since I don't have the
source for any of the finicky programs, I can't say for sure what they are
doing wrong, but since I am a very boring programmer (I pay attention to
Apple's guidelines and crib a good deal of sample code from them) I have never
been able to reproduce the problem ( haven't tried, since no one pays me to try
to reproduce a bug)  My suspicion is that the programs in question are just
being explicitly stupid masking out suspend events generated after the menu is
selected. I *THINK* that if your program acts as if it can take suspend events,
it can then refuse them in the mask passed to _WaitNextEvent, and the system
will not switch it to the back until it accepts the suspend. I have not been
able to find a solid confirmation of this, but a couple of places in IM6 imply
that if you have a SIZE resource that has the flag set to get suspend/resume
events, you don't get swapped out until you actually recieve the event.

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Date: 4 Nov 92 15:11:37 GMT
Organization: Oberlin College Computer Science

Hello-
    The problem is that when applications are busy and dim the
menu bar, the user can no longer change the foreground application
with the aplication menu.  I have had this problem.
    The reason is that after dimming the menu bar, some
applications ignore mouse down events in the menu bar.  They figure
that everything is dim, why even try to handle an event.  I believe
that multifinder and perhaps Sys7 patch (is it MenuSelect?  I forgot)
to see if the app menu has been clicked on.
    The solution is to always handle menus.  If your app is busy,
let the user pull down any menu he/she wants.  The menus will be dim,
of course, and they won't be able to do anything, but the application
menu will then be availible.

- -matt hall
- --
- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-6613 (That's a Cleveland Area code. Lucky Me)

"Life's good, but not fair at all"  -Lou Reed

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: Wed, 4 Nov 92 12:53:46 EST
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Sandra Stewart-Cole) writes:
> selected. I *THINK* that if your program acts as if it can take suspend events,
> it can then refuse them in the mask passed to _WaitNextEvent, and the system
> will not switch it to the back until it accepts the suspend. I have not been
> able to find a solid confirmation of this, but a couple of places in IM6 imply
> that if you have a SIZE resource that has the flag set to get suspend/resume
> events, you don't get swapped out until you actually recieve the event.

This is not correct. Apple documentation, particularly technical notes,
emphasize that you can not "delay" or otherwise ignore a SUSPEND event.
When you are told you are going to be suspended, it is going to happen,
whether or not you accept the event. You must honor SUSPEND and take
appropriate action, or you will be surprised.

I do not remember off hand how the App Menu functions, but there is
NOT ONE SINGLE LINE OF CODE in uAccess that refers to this menu. When
I am in yielding loops, I dim all of my menus, and handle Apple Menu
picks with calls to opendeskacc, so either the app menu looks like
a desk acc pick, or it is handled in MenuSelect.


tim endres - [e-mail]  -or- tbomb!time
ICE Engineering, Inc - 8840 Main St, Whitmore Lake, MI 48189
Phone [phone] - FAX [phone]
USENET - a slow moving self parody... ph

---------------------------

From: [e-mail] (Michael A. Kelly)
Subject: C.S.M.P. Digest Easy View format file


This is a format file for reading the C.S.M.P. Digest with Easy View.


(This file must be converted with BinHex 4.0)



---------------------------

End of C.S.M.P. Digest
**********************